Skip to content

Conversation

@gpanders
Copy link
Member

Add an option to StartParams that tells the container runtime which host namespaces the container should share. For now we only allow sharing the PID namespace. This is what the production container runtime on Cloudflare does today by default, so the default value is ["pid"]. However, in the future we will change this default behind a compatibility flag and this option will allow users to preserve the old behavior if they need to.

Closes CC-6790.

Add an option to StartParams that tells the container runtime which
host namespaces the container should share. For now we only allow
sharing the PID namespace. This is what the production container runtime
on Cloudflare does today by default, so the default value is `["pid"]`.
However, in the future we will change this default behind a
compatibility flag and this option will allow users to preserve the old
behavior if they need to.

Closes CC-6790.
@gpanders gpanders requested review from a team as code owners February 11, 2026 17:22
@gpanders gpanders requested a review from gabivlj February 11, 2026 17:22
@github-actions
Copy link

The generated output of @cloudflare/workers-types has been changed by this PR. If this is intentional, run just generate-types to update the snapshot. Alternatively, you can download the full generated types:

Full Type Diff
diff -r types/generated-snapshot/latest/index.d.ts bazel-bin/types/definitions/latest/index.d.ts
3731a3732
> type HostNamespace = "pid";
3745a3747
>   hostNamespaces?: string[];
diff -r types/generated-snapshot/latest/index.ts bazel-bin/types/definitions/latest/index.ts
3740a3741
> export type HostNamespace = "pid";
3754a3756
>   hostNamespaces?: string[];

@kentonv
Copy link
Member

kentonv commented Feb 11, 2026

Instead of making this part of the API, and then introducing a compat flag to set the default, I think the compat flag should just directly control the PID namespace behavior.

It seems unlikely that we would want to give people the ability to share other namespaces in the future -- in fact, it sounds like sharing the PID namespace itself may have been a mistake. Users don't really want to know about the host layer, and we don't really want them to know about it. But we accidentally gave them visibility into the PID namespace and turning that off could inadvertently break people. That's exactly the use case for a compat flag, but I don't think we really want to offer this as an API unless we envision good reasons why people would legitimately want it.

@kentonv
Copy link
Member

kentonv commented Feb 11, 2026

(Also side note for anyone else wondering, like I was: the container lives inside a VM. There's only one container per VM. The container boundary is not the security boundary; the VM is. So nothing security-sensitive is exposed here, it's just a matter of abstraction.)

@gpanders
Copy link
Member Author

Instead of making this part of the API, and then introducing a compat flag to set the default, I think the compat flag should just directly control the PID namespace behavior.

It seems unlikely that we would want to give people the ability to share other namespaces in the future -- in fact, it sounds like sharing the PID namespace itself may have been a mistake. Users don't really want to know about the host layer, and we don't really want them to know about it. But we accidentally gave them visibility into the PID namespace and turning that off could inadvertently break people. That's exactly the use case for a compat flag, but I don't think we really want to offer this as an API unless we envision good reasons why people would legitimately want it.

Makes sense to me. I'll rework the PR.

@gpanders
Copy link
Member Author

The direction is sufficiently different that I think it's worth creating a separate PR. I'll link it here when it's open.

@gpanders gpanders closed this Feb 11, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants